In software design, functionalities are normally implemented using software source code such as functions, procedures, or routines. This is true for both procedural and object oriented design, although in the latter these are often referred to as “methods.” As used herein, these entities are collectively referred to as “functions.” Functions may be used, for example, to implement low-level functionalities as simple as a single mathematic operation, and high-level functionalities that control components of a large system. As used herein, the term “unit” may refer to software units that are analogous to functions. Note that units are not necessarily source code based, but may instead be model based to represent a functionality partition of similar scope. Manually modeling the internal logic (e.g., algorithm) of any given arbitrary structure for a single unit and/or a multitude of units can be a time consuming, error-prone, and expensive task. Moreover, it can be difficult to keep track of high and low level requirements and how those requirements map to various functions and/or units. As a result, there are significant difficulties and associated costs to maintain, evolve, enhance, transform, and re-innovate complex, long-lived, systems (e.g., such as safety-critical avionics and ground system software).
Note that no single existing model-based design system can effectively solve these problems and challenges. Generally speaking, model-based design tools fall into two major categories: 1) tools for reactive systems (such as real-time control systems), and 2) tools for regular systems. Tools for reactive systems are targeted for a specific kind of application. They tend to have very restricted and limited modeling constructs, and thus may not be appropriate for complex, interactive, information systems. Tools for regular systems are generally able to handle interactive systems, but their design philosophy is usually focused on objected oriented design. As a result, they lack the ability to fully, efficiently, and effectively support complex, long-lived, safety critical systems. Note that complex, long-lived, safety critical systems may be characterized by stringent certification requirements and variants released over the life of the product line that still need to be maintained many years after their initial release. The ability to bridge the investment and accumulation of knowledge from the past in complex, long-lived, safety critical system and the transformative re-innovation for future products in years to come does not exist. Activity diagrams, as often used in Unified Modeling Language (“UML”) based modeling, is only useful when a new software system is designed from scratch using very fragmented classes and may not be helpful with existing arbitrary logic.
It would therefore be desirable to facilitate arbitrary software logic modeling in an automatic and accurate manner.